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1 Introduction 


1.1 Purpose of Paper 

On May 21-26. 2012, the third annual NASA Lunabotics Mining Competition will be 
held at the Kennedy Space Center in Florida. This event brings together student teams from 
universities around the world to compete in an engineering challenge. Each team must design, 
build and operate a robotic excavator that can collect artificial lunar soil and deposit it at a target 
location. Montana State University. Bozeman, is one of the institutions selected to field a team 
this year. This paper will summarize the goals of MSU’s lunar excavator project, known as the 
Autonomous Lunar Explorer (ALE), along with the engineering process that the MSU team is 
using to fulfill these goals, according to NASA's systems engineering guidelines. 

1.2 Project Objectives and Problem Definition 

Each student design produced for the competition is meant to serve as a possible 
inspiration or proof-of-concept for future NASA projects. The efficient realization of a long- 
term human presence on the moon will require astronauts to make use of local resources. Lunar 
soil, better known as regolith. can be processed to obtain vital substances (e.g. water and 
oxygen); therefore, machinery that mines and transports regolith is likely to be an important 
component of future moon missions. Thus, the challenges posed by the Lunabotics Mining 
Competition are directly relevant to NASA's goals. The competition is also intended to promote 
workforce development in science, technology, engineering, and mathematics (STEM) 
disciplines, by engaging college students in an exciting, challenging project that will provide 
them with realistic engineering experience [1], 

Although the competition has a variety of components (e.g. team spirit and outreach 
projects), this paper focuses on the design of the actual mining equipment. Each team is required 
to design and construct a mobile robot, which must be either autonomous or remotely operated 
over a wireless network (or some combination of the two). The robot will operate in a 7.38 m by 
3.88 m arena filled with lunar regolith simulant. It must be able to traverse an obstacle area 
containing rocks and craters, collect regolith simulant in the mining area, then travel back across 
the obstacle area and deposit the mined material in a collection bin. Ten minutes will be allotted 
for each mining attempt, and the robot must deposit at least 10 kg of simulant in that time to 
qualify to win. Additional points will be awarded for dust-resistant designs, autonomous 
designs, and the inclusion of a way to measure power usage. Other optional goals for which 
teams may earn points include minimizing the weight and wireless bandwidth usage of the robot 
[ 2 ], 

1.3 Deliverables 

The Montana State University team must deliver the following: 

• A mobile robot, capable of performing the tasks required by the competition while 
conforming to all rules and constraints; 

• A working wireless control system, including a computer, a wireless access point, handheld 
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control ler(s), and any other necessary items; 

• A beacon(s) to assist the robot with autonomous navigation; 

• A document including a description of the team's robot, a parts list and diagram, and an 
explanation of the robot’s operations and possible safety hazards; 

• A video showing at least one full cycle of the robot's operations (including excavation and 
unloading of material), between 0.5 and 5 minutes long. 

The video and documentation are due on April 30. 2012. and may be submitted to 
competition staff via e-mail. All other deliverables are due on May 21. the first day of the 
competition. However, in the MSU team's case, the robot must be completed by May 9, since 
they plan to ship it to Kennedy Space Center and must allow time for it to arrive. The wireless 
control system and beacon(s) should also be completed by May 9. so that they can be tested 
together with the robot. 

2 Systems Engineering Process 

2.1 Systems Engineering Process Planning 

2.1.1 Project Life Cycle 


The MSU ALE project can be broken up into the same standard phases traditionally used 
for NASA programs and projects. The life cycle envisioned for our project appears in Table I . 


Table 1: MSU ALE Project Life Cycle 

Phase 

Anticipated Time 
Frame 

Tasks to Accomplish in this Phase 

Pre-Phase A and Phase A: 
Concept Studies and 
Development 

Sept. 1.2011- 
Sept. 16, 201 1 

Enter the competition. Since the rules of 
the competition already establish the 
project concept, there is little for the team 
to do in the way of concept studies. 
Define top-level requirements and pass 
System Requirements Review. 

Phase B: Preliminary Design 

Sept. 17, 201 1 - 
Oct. 7, 201 1 

Establish preliminary design and pass 
Preliminary Design Review. 

Phase C: Final Design and 
Fabrication 

Oct. 8. 201 1 - Jan. 
21. 2012 

Finalize design. Pass Critical Design 
Review. Obtain or fabricate all system 
components. Pass Production Readiness 
Review. 

Phase D: Assembly. 
Integration and Test 

Jan. 22, 2012- 
May 9.2012 

Integrate all systems and assemble the 
complete robot. Perform any needed 
calibrations of software and sensors. 
Perform verification and validation of all 
sub-systems and the complete system. 
Crate robot for shipment. 
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Phase E: Operations and 
Sustainment 

May 10, 2012 - 
May 26, 2012 

Operate robot in the pre-competition 
practice rounds and the competition itself. 
Adjust and repair robot between sessions, 
as allowed by the rules. 

Phase F: Closeout 

May 26, 2012- 
June 30, 2012 

Crate robot for shipment. After robot 
arrives at MSU. prepare for display in one 
of the campus buildings. 


2.1.2 Concept of Operations 

The Concept of Operations (Con-Ops) summarizes the assigned tasks and capabilities 
required for ALE, from the perspective of the end user. It includes all of the optional 
competition goals which the MSU team chose to strive for in their design. The Lunabot must be 
able to perform the following operations: 

• Perform three complete operation cycles (navigate to mining area, excavate simulant, 
navigate to bin. and deposit regolith) in 10 minutes or less. 

o Autonomously traverse a bed of regolith simulant to reach the mining area, 
without becoming stuck or kicking up large dust clouds. 

■ Roll over/through small rocks and craters. 

■ Autonomously navigate around obstacles that are too large to roll 
over/through. 

o Autonomously excavate at least 35 kg of simulant (per operation cycle) without 
kicking up excessive amounts of dust, and collect it in a receptacle on the robot, 
o Autonomously follow a navigation beacon to the designated collection bin. 
o Autonomously remove regolith from the onboard receptacle and deposit it in the 
collection bin, without leaving any part of itself (e.g. a container) in the bin. 
o In case of a failure of autonomous operations, accept commands sent wirelessly 
from a handheld controller to guide navigation, excavation, and deposition. 

• Measure its own power consumption during all operations, and report it to the Lunabot's 
controllers at the end of each competition run. 

• Repeat all of the operations above at least twenty-four times (twenty times in testing, 
twice in practice rounds and twice in the competition itself). 

2.1.3 Constraints 

All of the constraints for MSU ALE were derived from the official competition rules. 
They include the following: 

• Mass: Less than 80 kg. This includes the robot's power systems and any navigation 
beacons, but does not include communications hardware that is not attached to the robot. 

• Size: In its starting configuration, the robot must fit inside a volume of 1 .5 m long X .75 
m wide X .75 m tall. It may deploy or expand itself to larger dimensions, but may not 
exceed 1 .5 m tall at any time. 

• Setup Time: Less than 10 min. 
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• Bandwidth: The average wireless bandwidth used may be no more than 5 Mbps. 

• Wireless Range (robot to access point): At least 50 ft. 

• Wireless Range (access point to control center): At least 200 ft. 

2.1.4 Budget 

The MSU ALE team has been given a budget of $4500 dollars by the team's faculty 
advisors. These funds will be distributed among the various subsystems of the Lunabot. as 
shown in Table 2. 


Table 2: MSU ALE Project Budget 

Subsystem 

Allocated Funds 

Mechanical 

$2500 

Electrical 

$1500 

Computer 

$0 (reused 201 1 parts) 

Testing 

$500 

Total 

$4500 


2.2 Requirements Analysis and Validation 

The top-level system requirements for MSU ALE flow down from a combination of the 
Con-Ops, the constraints, and other stipulations in the rules. They are listed below, along with 
the tests necessary for their verification and validation. Refer to section 5.2 for fuller 
descriptions of the tests mentioned in the list. All requirements for which a test is not mentioned 
will be verified and validated by inspection or demonstration. 

Functional: 

1) The robot shall be mobile, and shall be capable of traversing a bed of lunar regolith 
simulant without becoming mired in the material. Verify with movement test on regolith. 

2) The robot shall either surmount or navigate around all obstacles (rocks and craters) that 
may lie in its path, and reach its designated mining area. Verify with obstacle climbing 
test and autonomous operation test on robot. 

3) The robot shall gather lunar regolith simulant without using the walls or floor of the 
competition arena as an aid, and shall hold it for transport to a designated bin. 

4) The robot shall navigate to the designated bin and deposit its collected regolith therein, 
without depositing any part of itself (e.g. a container) in the bin. 

5) The robot shall perforin all of the functions above under autonomous control, with the 
ability to switch to teleoperated control in the event of a failure. Verify with autonomous 
operation test. 

6) The robot shall avoid throwing loose dust into the air (except when depositing regolith). 
Verify with combined Locomotion and E&D System test on regolith. 

7) The robot shall not employ any process or technology that would not be feasible for use 
on the moon, such as suction, sonar, or pneumatic rubber tires. 

8) The robot shall not employ any process that alters the regolith, or otherwise interferes 
with the uniformity of subsequent competition attempts. 
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9) The robot shall not use any explosives or ballistics. 

1 0) The robot shall not interfere with or sabotage the robots belonging to other teams. 
Performance: 

I I ) The robot shall be capable of performing three operation cycles (move-dig-move-dump) 
in 10 minutes, and shall deposit at least 35 kg of regolith in the bin per cycle, whether 
under autonomous or teleoperated control. This requirement may be relaxed to a 
minimum of one trip and 10 kg of regolith if needed. Verify with competition trial runs. 

12) After being placed in the arena, the robot shall require less than 10 minutes to be 
prepared for operation by the team members. Verify with competition trial runs. 

Reliability: 

1 3) The robot shall be reliable and durable enough to complete at least twenty test runs and 
four ten-minute competition attempts without a breakdown. 

14) The robot shall be constructed in a dust-tolerant fashion, such that sensitive parts cannot 
be clogged or fowled with dust. 

Safety: 

1 5) The robot shall be equipped with a red stop button, at least 5 cm in diameter and readily 
accessible, which will instantly disable it and halt all operations if pressed. 

1 6) The robot shall operate entirely inside the arena, without ramming or damaging the walls. 
Verify with autonomous operation test. 

Physical: 

1 7) The robot and its beacon shall be self-powered. 

1 8) When in its starting configuration, the robot shall fit inside a volume of 1 .5 m long X .75 
m wide X .75 m tall. It shall never exceed 1.5 m in height. 

1 9) The robot and its navigation beacon shall have a combined mass of less than 40 to 80 kg. 

20) The wireless communication system shall use less than I to 5 Mbps of bandwidth. 

2 1 ) The communication link between wireless access point and robot shall have a range of at 
least 50 ft. 

22) The communication link between wireless access point and control center shall have a 
range of at least 200 ft. 

23) The wireless communication system shall be composed of standard 802.1 I hardware. It 
shall use only one channel. 

Requirements for MSU ALE's various sub-systems flow down from the top-level 
requirements listed above; these, in turn, flow down to create requirements for specific 
components. Due to space constraints, these lower-level requirements will not be listed here. 

2.3 Functional Analysis and Allocation 

The MSU ALE project can be simplified by logically breaking it into a hierarchy of 
systems. The complete system resides on the first level of the hierarchy. The project was 
divided into three parts by engineering discipline, since this made team organization more 
convenient. Thus there are mechanical, electrical, and computer sub-systems on the second 
level. These sub-systems are further divided into functional units on the third level. Each of 
these units handles a specific task on behalf of the robot (e.g. “Supply power" or "Move the 
robot over the regolith”). The complete system hierarchy is represented graphically in Figure I. 
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Figure I. The MSU Lunabot's system hierarchy. 


The Functional Flow Block Diagram (FFBD) in Figure 2 describes the Lunabot's mission 
as a timeline of functions. Each function may contain sub-functions, which appear in lower 
levels of the diagram. Third-level diagrams for Functions 2.3 and 2.4 are not shown, since they 
are very similar to 2.1 and 2.2, respectively. If autonomous functionality fails. Functions 2.1.1 
and 2. 1 .2 are replaced by new functions that receive and decode user commands from the 
wireless link. 



Figure 2. Functional Flow Block Diagram for the MSU Lunabot. 


2.4 Synthesis 

2.4.1 Decisions Regarding COTS vs. 1)1 

In every engineering project, the project team must decide whether to design and 
fabricate certain components themselves, or rely on pre-existing, commercially available 
products. Components that are designed in-house are referred to as Developmental Items (DIs). 
while pre-designed products that are simply purchased are called Commercial Off-The-Shelf 
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(COTS) items. Each choice has its advantages and disadvantages. COTS products reduce the 
time and cost of development, and may be more reliable than Dls, since they have already 
received extensive professional testing. However. Dls are more customizable, and may be able 
to provide a form or function that simply does not exist among COTS parts. Dls can also reduce 
material costs in some cases. The MSU Lunabotics team has chosen to use COTS parts for all 
components of the robot's electrical and computer systems (see section 2.5.1 for some pertinent 
trade studies). However, most parts of the mechanical system are Dls. including the frame, 
wheels, and excavation/deposition system. Given the novelty of the robot's design, it is unlikely 
that suitable COTS equivalents for these parts could be found, with the exception of the wheels. 
Custom wheels were chosen because most commercially available wheels are not designed for 
the lunar environment. Custom wheels are also well within the team's fabrication abilities, and 
are easy to optimize for strength, low weight, and traction. 

2.4.2 Reuse 

Because Montana State University has participated in the Lunabotics Mining 
Competition for the past two years, items from MSU's previous designs are available for 
potential reuse. Due to changes in the competition rules and a re-evaluation of the 
digging/dumping techniques employed by the older robots, little of the mechanical design will be 
re-used. However, this year's design will use motors, motor controllers, and actuators very 
similar to those employed by the 2010 MSU Lunabot, because they proved to deliver a good 
combination of performance and reliability. The 201 I Lunabot's design incorporated an X-Box 
Kinect and an Arduino microcontroller, and those design elements are also being re-used, along 
with the entire wireless networking setup (including the code). Because of the new requirement 
for autonomy, the Kinect now plays a more essential role in the design. Although these elements 
will be re-used in a design sense, some of the individual parts will not be re-used, due to a desire 
to keep the old robots intact for display and demonstration purposes. I lowever, the lead-acid 
batteries and communication hardware from the 201 I Lunabot will be re-used. 

2.5 Systems Analysis and Control 

2.5.1 Trade Studies 

When it became necessary to choose among multiple alternatives for a subsystem design 
or a component, the MSU ALE development team often used decision matrices to make their 
selection. These matrices are reproduced below in Tables 3 through 9. A decision matrix 
explores each option's ability to meet the design requirements, and provides a formal means of 
rating and comparing the options. The team scored all options on a scale of one to five in each 
category, with larger numbers being more desirable. All categories were weighted equally. 

Assuming all other systems retain some minimum level of functionality, the performance 
of the excavation and deposition (E&D) system is the most likely to determine success in the 
competition, since it directly affects the amount of regolith collected. The MSU team considered 
three alternative designs for this system: a hollow, rotating drum with scoops on the outside to 
gather regolith into the interior; a traditional shovel, such as might be found on a front-end 
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loader; and a conveyer belt with numerous small scoops attached, which would convey regolith 
to a large bucket that could tip back to unload its contents (much like a dump truck). Each of 
these design variants has been employed with good success by at least one Lunabotics team in 
past years. The MSU team chose the drum, which, though difficult to manufacture, greatly 
simplifies the digging and control system. The decision matrix for the E&D system appears in 
Table 3. 


Table 3: Decision Matrix: Excavation and Deposition System 


Drum 

Shovel 

Belt/Bucket 

Cost 

3 

3 

2 

Reliability 

4 

2 

1 

Design Complexity 

3 

4 

1 

Power Consumption 

3 

4 

2 

Weight 

3 

3 

1 

Ease of Autonomous 
Control 

5 

4 

5 

Dust Mitigation 

5 

3 

1 

Regolith Collection 
Capacity 

4 

3 

5 

Manufacturability 

3 

4 

2 

Total 

33 

30 

20 


Tracks and wheels were both contemplated for the most basic components of the 
locomotion system. The use of skid steering was anticipated for both approaches. Wheels were 
ultimately selected, particularly because of their greater simplicity of construction, lower cost, 
and lower tendency to throw dust in the air. See Table 4 for the relevant decision matrix. 


Table 4: Decision Matrix: Driving Elements (Locomotion System) 


Wheels 

Tracks 

Cost 

5 

1 

Reliability 

3 

3 

Design Complexity 

5 

2 

Power Consumption 

4 

2 

Weight 

5 

2 

Required Computations 

3 

3 

Dust Mitigation 

4 

3 

Regolith Collection Capacity 

4 

5 

Manufacturability 

4 

1 

Total 

37 

22 


No suspension system was used on past MSU Lunabot designs. However, the lack of any 
suspension increases the probability of getting stuck or burning out a motor, due to the 
possibility of one or more wheels losing contact with the ground. Such a scenario was 
responsible for the failure of the 201 1 MSU Lunabot, which had serious issues with burning out 
motors, destroying gearboxes, and becoming mired in the regolith. For these reasons, the team 
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considered adding a suspension system this year. The two options considered were an active 
suspension system, featuring a linear actuator to adjust the height of each wheel, and a passive 
suspension system based on a single swing-arm and spring for each wheel. The decision matrix 
for the possible suspension system is featured in Table 5. The team eventually chose to include 
the spring-based suspension system, to provide the robot with improved traction without 
introducing too many complications. 


Table 5: Decision Matrix: Suspension (Locomotion System) 


Actuators 

Springs 

None 

Cost 

2 

3 

5 

Reliability 

4 

5 

4 

Design Complexity 

2 

3 

4 

Power Consumption 

2 

5 

5 

Weight 

2 

3 

5 

Required 

Computations 

2 

5 

2 

Dust Mitigation 

3 

4 

4 

Regolith Collection 
Capacity 

4 

4 

1 

Manufacturability 

2 

3 

4 

Total 

23 

35 

34 


For the power source, a high-voltage DC power supply was desired in order to run the 
chosen 24 V motors (re-used from the first year design). Two sealed lead-acid batteries were 
available to re-use from the second year robot, making the cost of this option zero. The lithium- 
ion batteries received a low "power supplied” rating in spite of their higher power density, 
because it would cost a great deal to obtain enough of them to supply large amounts of power. 
Their tendency to lose capacity at high temperatures is also of concern, due to the anticipated 
weather at the competition location. NiCad battery packs are small, and it would be necessary to 
combine many of them to obtain the needed voltage and current, resulting in increased 
complexity and wasted space. For these reasons, the lead-acid batteries were chosen ( Fable 6). 


Table 6: Decision Matrix: Power Supply (Power System) 


Sealed Lead-Acid 
Batteries 

NiCad Battery 
Packs 

Lithium-Ion Batteries 

Weight 

2 

3 

4 

Power Supplied 

5 

2 

2 

Temperature 

Dependence 

4 

4 

2 

Cost 

5 

2 

2 

Total 

16 

11 

10 


The experiences of past Lunabotics teams have taught the MSU team that designing, 
assembling, and debugging a compact custom-made motor controller circuit can be very 
difficult. A COTS option was chosen instead, for the sake of simplicity and reliability. Refer to 
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Table 7 for details. 


Table 7: Decision Matrix: Motor Control System 


Off-the-Shelf Controllers 

Custom Circuits 

Reliability 

4 

3 

Complexity 

5 

2 

Cost 

4 

3 

Total 

13 

8 


Although the main power source can power the motors and actuators directly, it must be 
regulated to lower voltages in order to run certain other components (e.g. the X-Box Kinect). 
The alternatives considered for powering these items included a COTS regulator, a custom 
regulator circuit, and separate small battery packs that would put out a lower voltage from the 
beginning. A COTS regulator was decided upon, again for the sake of simplicity and reliability. 
The relevant decision matrix can be found in Table 8. 


Table 8: Decision Matrix: Voltage Regulation (Power System) 


Off-the-Shelf Voltage 
Regulator 

Custom Circuit 

Independent Battery 
Systems 

Reliability 

4 

3 

3 

Complexity 

5 

1 

2 

Cost 

3 

2 

2 

Total 

12 

6 

7 


The last electrical component remaining to be chosen was the one that would measure 
and record the robot's power consumption, for reporting to competition officials at the end of 
each round. The commercially available "Watt's Up" meter proved far superior to the other 
possibilities considered (both of which would have required some circuit design and 
microprocessor programming) for ease of use and reliability; therefore, it was chosen. Refer to 
Table 9. 


Table 9: Decision Matrix: Power Monitoring (Power System) 


“Watt's Up" Meter 

Current-Sensing 1C 

Custom Circuit 

Reliability 

5 

2 

1 

Complexity 

5 

3 

2 

Cost 

3 

2 

2 

Total 

13 

7 

5 


No decision matrices were generated for the computer system; the computer sub-team 
relied instead on more qualitative discussions. Their first major decision concerned whether to 
perform the autonomous control calculations with an on-board computer, or a remote computer 
that would receive data from the Lunabot and transmit movement commands back. The second 
option was discarded, because it would place unacceptable bandwidth demands on the wireless 
network. A netbook was selected to be the onboard computer, due to its versatility, ease of use. 
and low space requirements. 
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Since the remote computer was removed from consideration, the wireless network was 
only needed for 1) receiving status updates from the robot and 2) sending remote control 
commands in the event of an autonomous control failure. The team contemplated the Berkeley 
Sockets API and the SSH protocol as options for transmitting this information. Although the 
Berkeley API is more customizable and could result in lower bandwidth usage, the team settled 
on SSH for its simplicity and stability, choosing to spend more of their development time on the 
autonomy and vision subsystems. 

Since the robot must detect the shape and location of obstacles in real time, but does not 
need other details, a depth-mapping device was judged to be the best way to realize the vision 
system. A system consisting of either two Xbox Kinects or an array of infrared sensors was 
envisioned. The Kinects offered superior simplicity and ease of development in every way, due 
to their USB interfaces (easy to connect to a computer) and the availability of an open source 
library for low-level processing of Kinect depth maps. For these reasons, they were chosen as 
the basis of the vision system. 

The Q-learning algorithm was chosen as the basis of the autonomous control calculations, 
because of its reliability, computational efficiency, and ability to deal with a changing 
environment. (Since the positions of the obstacles in the arena are randomized after every round, 
the course cannot be learned ahead of time.) Using data from the vision system, the robot will 
detect objects in the obstacle area, represent the course and its position therein as a state space, 
and assign rewards to different state-action pairs in the space. Finally, it will generate a policy (a 
group of state-action pairs that constitute a path through the course) that maximizes its reward. 
These calculations will be repeated and the policy updated in real time as the robot travels 
through the obstacle course. 

2,5.2 Risk Management 

To ensure preparedness for unpleasant surprises at the competition, the team attempted to 
predict the various ways in which MSU ALE might fail. Each possible failure (referred to as a 
risk) was assigned a severity and a likelihood of occurrence, on a scale of one to five, with five 
being the most likely/most severe. The risks were then tabulated in a Risk Analysis Chart (see 
Figure 3). This chart can be used to prioritize risks for mitigation. Risks that lie in the red 
region of the chart, i.e. those that have both a relatively high likelihood and highly significant 
consequences, are the most serious ones and should be dealt with first. Risks in the green region 
are low-priority, and can be mitigated as time allows. 

A mitigation strategy was devised and implemented for each risk, as follows: 

I ) Failure of Autonomy: This risk encompasses any malfunction or inadequacy of the robot's 
autonomous navigation system, including an excessively slow rate of travel through the obstacle 
course, collisions with obstacles or arena walls, the robot becoming stuck due to poor navigation, 
or the robot being unable to generate a policy/movement plan. This risk is mitigated by the 
inclusion of a protocol which allows the user to send remote commands through the wireless 
link, and take over navigation in case of a failure. The risk can also be reduced by extensive 
testing prior to the competition, which will create opportunities to adjust and calibrate the 
algorithm. 
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2) Surge Current Damaging Motors: It is possible that current spikes due to rapid speed changes 
or reversal of the motors could destroy them. This risk will be mitigated by writing motor 
control code that will gradually ramp the speed of the motors up and down at a safe rate. Spare 
motors will be kept on hand at the competition site as well. 


3) Stall Current Damaging Motor Controller: The motors chosen for this robot can draw up to 29 
A of current when stalled, and this could be enough to burn out the motor controllers. However, 
this circumstance was judged unlikely, due to the care that was put into designing the wheels and 
the suspension system to ensure good traction and ground contact for each wheel, and the quality 
of the motor controllers. To mitigate this risk, spare motor controllers will be kept on hand at the 
competition site, so that any damaged controllers can be replaced between rounds. 


4) Propulsion Failure: If the wheels do not have enough traction to grip the regolith, the Lunabot 
could have difficulty moving, resulting in a propulsion failure due to wheel slippage. If this risk 
is realized, it could be dealt with by changing the height and/or angle of the wheel grousers, a 
task which can be performed at the competition site if necessary. 
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Figure 3. Risk Analysis Chart with legend. 


5) Barrel Mining Failure: This risk encompasses possible issues with the E&D system, especially 
shearing or warping of the drum under stress. If the drum proves too weak to dig deep into the 
regolith. the problem can be reduced by not lowering it as far into the soil. 

6) Scooping Depth too Shallow: If the scoops on the outside of the drum are so shallow that they 
collect too little regolith with each spin of the drum, the robot may fail to meet its collection rate 
requirements. This risk can be avoided through extensive testing before the competition, 
coupled with modification of the scoops if needed. 
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2.5.3 System Interface Definition and Management 

A diagram of the interfaces between the many sub-systems in MSU ALE appears in 
Figure 4. The Structural System has mechanical interfaces with numerous components, because 
it provides support and attachment points for all of them. Since the Power System supplies all of 
the electrical and computer components, it has an electrical interface with each of them. The 
Locomotion and E&D motors must also receive electrical signals from the Motor Control 
System. The remaining interfaces are fairly self-explanatory. 


Structural System 

X 


Key: 

< Data Interface 

< Electrical Interface 

< Mechanical Interface 


. 

T 

Power System 

Figure 4. Interface diagram for MSU ALE. 

Due to the small, tight-knit nature of the MSU team, the creation of Interface Control 
Documents was judged less efficient than regular meetings of the different sub-teams. Each 
group met with the others at least once a week, providing an opportunity to discuss compatibility 
and possible changes to the interfaces as the need arose. The ensured that all engineers were 
kept up-to-date on the interface designs they needed to connect their system with those of the 
other teams. 

3 Transitioning Critical Technologies 

For MSU ALE, a critical technology would be one that is essential to the design of the 
Lunabot and has not yet been developed. The development of all critical technologies must be 
completed before they are needed for integration into the Lunabot or one of its sub-systems; 
otherwise, progress on the project will be stalled. The vast majority of the components used in 
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the Lunabot are either COTS parts, or custom-built parts that are based on proven technologies. 
The only exceptions are the Q-learning algorithm and some of the associated processing 
algorithms used to extract Q-learning inputs from the Kinect images. Although Q-learning has 
been used for robot navigation in the past, the ALE Computer System sub-team will be creating 
their own implementation, rather than relying on a pre-existing library. An open-source library 
containing routines that perform low-level processing on Kinect images is available, and will be 
used by the team; however, they must write their own code for the final step, which translates the 
depth map images to actual obstacle sizes and locations. The team was required to code these Q- 
learning and image processing tasks themselves because no publicly available code for these 
elements exists. 

The use of these critical software technologies introduces both operational and schedule- 
related risks. Because of the inherent difficulty of estimating how many software bugs will 
appear and how much time will be needed to solve them, it is entirely possible that the 
autonomous control software will be delivered behind schedule, reducing the amount of time 
available for testing. It is also possible that the final code will not be sufficiently effective to 
allow the robot to operate in the given obstacle environment. Either of these outcomes could 
ultimately lead to a "failure of autonomy" during the competition, as discussed in Section 2.5.2. 
The inclusion of the teleoperation option as a backup is the primary method of mitigating this 
risk. Although the ability to send commands to the robot by remote control would prevent a 
failure of autonomy from terminating the mission, the team could still fail to gain the additional 
points offered for successful autonomous operation. Extensive testing and adjustment of the 
algorithms will be performed to reduce the probability of a failure of autonomy, as schedule 
constraints allow. 

4 Integration of Systems Engineering Effort 

4.1 Team Organization 

The MSU ALE team is headed by three faculty advisers, one from each of the 
departments of Mechanical Engineering, Electrical and Computer Engineering, and Computer 
Science. Students from all three of these departments signed up for the project; therefore, it 
seemed convenient to separate the team into sub-teams by discipline, with each sub-team having 
one faculty adviser as its supervisor. Two students were assigned to the electrical team, three to 
the mechanical team, and three to the computer team. One additional student (an Electrical 
Engineer) was assigned the specific task of preparing paperwork and developing outreach 
activities, leaving the others free to concentrate primarily on design, fabrication, and testing. 

4.2 Design Reviews 

Multiple reviews were conducted during the design process, to ensure quality and provide 
milestones that would keep the work moving at a reasonable pace. Each review allowed the 
project advisers, other faculty members, and professionals in related fields to critique the team's 
plans and suggest improvements. A production readiness review was also conducted after the 
design work was complete, to check and finalize the team's plans for manufacturing and testing 
the robot. The reviews are described below in Table 10. 
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Table 10: Ma jor Reviews of the MSU ALE Project 

Review 

Purpose 

Pass Date 

System Requirements 

Ensure that the team has properly 
understood and specified the requirements 
of the project. 

September 16, 201 1 

Preliminary Design 

Establish that the basic, system-level design 
proposed by the team is solid and practical. 

October 7, 201 1 

Critical Design 

Ensure that the design is complete, and 
check all of its details for flaws. 

December 2, 201 1 

Production Readiness 

Review the team's plans for manufacturing 
and testing the project, checking them for 
completeness and practicality. 

January 21, 2012 


4.3 Scheduling 

Although the timing of the major reviews creates a basic schedule for MSU ALE, it was 
necessary to create more detailed schedules to help the sub-teams pace themselves on specific 
tasks. An early schedule generated by the team appears in Figure 5. 



llA S*«MKtartbMft«i 

Start 

11/M 

End 

1/* 

KContpl. j( 

traroc 

Suspension Arms/Suspenslon 

Wheels 

Bucket/3>yymf 

11/22 

11/28 

12/12 

12/20 

11/28 

12/12 

12/10 

1/9 

50* 

40* 

0* 

0* 

CS Components 

11/28 

1/9 


Autonomy 

Vision 

11/22 

11/28 

4/10 

4/10 

1/15 

11/30 

40* 

3* 

Motor Control 
Networluni 

11/22 

11/22 

25* 

ICO* 

£E Components 

11/28 

1/12 

10* 

Submit Report Draft and Website to Wataru 

11/28 

12/2 

100* 

New case for components 

11/28 

12/4 

W 

Ordering more motor controllers 

11/28 

12/6 

0* 

Soldering and Connecting wires to motor controllers 

12/6 12/12 

0* 

Mount Watts up Meter to case 

12/14 

12/14 

0* 

Connect Motor Controllers to laptop 

12/12 

12/15 

0* 

Mount Motor Controllers 

12/12 

12/16 

0* 

Connect motor controllers to digging actuators and digger motors 

l/l 

1/12 

0* 

Test Motor Controllers with ME system 

l/l 

1/12 

0* 

Mount Kill Switch to Lunabot 

1/8 

1/8 

0* 


■H 

mM 

l_L 


■UlJ 

1/9 

5/15 

0* 

Fta Problems from Testing 

1/9 

V15 

0* 

Sub task 2 

V15 

5/21 

0* 



■■■■ — I 



Figure 5. Preliminary schedule chart for the MSU Lunabotics Project. 


The schedule shown in Figure 5 proved impossible to meet, and had to be revised by the 
team at the time of the Production Readiness Review. The updated target deadlines for the 
remaining portions of the project, as of the PRR date, are as follows: 


• January 28: Design heading/positioning software 

• January 3 1 : Mount locomotion parts and shocks to the suspension arms 

• February 5: Mount arms to frame and temporary wheels to arms 

• February 5: Perform motor and gearbox integration test 
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• February 5: Find a source of regolith simulant (or similar substance) for testing purposes 

• February 6: Implement heading/positioning software 

• February 9: Design vision algorithms 

• February 1 1 : Mount all electrical components inside their protective Pelican case 

• February 1 1 : Test voltage regulator and motor controllers 

• February 17: Implement vision algorithms 

• February 18: Test I R sensors 

• February 1 8: Mount Pelican case, netbook, and other electrical components to frame 

• February 1 8: Test the Vision System 

• February 25: Develop and implement locomotion/digging control software 

• February 26: Test locomotion software in a test bed environment 

• February 29: Fabricate excavation drum and mount to digging arm 

• February 29: Mount all remaining mechanical parts (digging arm, actuators, digging 

motors) to frame 

• February 29: Integrate all software systems 

• February 29: Construct and fill regolith testing area 

• February 29: Test suspension system, motion, obstacle climbing ability, and Kinect Pan 

system with temporary wheels in place 

• March 10: Fabricate and mount competition-grade wheels 

• March 10: Perform all digging system tests 

• March 10: Begin on-board testing and debugging of autonomous control software 

• March 3 1 : Test mobility, suspension, digging, and autonomous control in the regolith 

testing area; perform simulated competition runs 

• April 30: Complete all software revisions and testing of autonomous operations 

• May 9: Crate the Lunabot and ship it to Kennedy Space Center 

• May 21-26: Attend and compete in the Lunabotics Mining Competition 

5 Implementation Tasks 

5.1 Development 

5.1.1 Mechanical System Development 

Using information about the properties of BP-1, the regolith simulant that will be used for 
the competition, the Mechanical team performed terramechanics calculations to determine the 
ideal values of parameters such as wheel size, grouser height, and minimum motor torque. They 
also employed load calculations to determine a minimum size of aluminum tubing for ALE's 
frame and the support system of the excavator drum. Solid Works models of some of their 
designs may be seen in Figure 6. After the designs were complete, the team fabricated all of the 
necessary custom parts in a machine shop on the MSU campus. 
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Figure 6. From left: Early Lunabot mechanical design, cutaway view of one wheel, final 
Lunabot mechanical design. All images generated in Solid Works. 


5.1.2 Electrical System Development 

All of the key electrical parts in the MSU ALE project are COTS parts. These include 
the power regulator, the motor controllers, the IR navigation beacon and receiver, and the 
microcontroller that serves as a translator between the netbook (in the Computer System) and the 
motor controllers. The team was required to select a specific COTS part to fill each task. Once 
these decisions had been made, the only remaining development work was to write a simple 
program for the microcontroller. Since the chosen microcontroller (an Arduino) came on a small 
demonstration board which included the necessary interfaces to the microcontrollers and 
netbook, no circuit design was required. 

5.1.3 Computer System Development 

The members of the Computer System team are required to code their own 
implementation of the Q-learning algorithm to guide the Lunabot’ s autonomous navigation. 

They must also produce code to extract inputs for the Q-learning algorithm from the Kinect 
depth map images, and code to translate the outputs of the Q-learning algorithm into specific 
movement commands for the robot. 

5,2 Testing 

5.2.1 COTS Verification 

All COTS parts must be tested when they arrive, to determine that they are not defective 
and meet all requirements. Such tests involve supplying the part with inputs thought to be 
representative of what it will encounter as part of the Lunabot, and observing or measuring its 
outputs (as applicable). 
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5.2.2 Code Verification in a Test Bed Environment 


Before being downloaded to the actual Lunabot. all code produced by the Computer 
Team must be verified in a test bed environment, e.g. a debugger. Such an environment supplies 
the code with more or less realistic inputs, and allows the team to observe the behavior of the 
program and capture its outputs. 

5.2.3 Integration Tests 

Testing of each component part in a system, as an independent unit, is not sufficient; after 
assembly, all parts must be tested together to ensure that system-level requirements are met. An 
integration test is designed to verify such complete systems. Multiple integration tests must be 
performed as the assembly process progresses up the system hierarchy. 

5.2.4 Tests on Regolith 

In previous years, the MSU Lunabotics teams have tested their robots in a sand-filled 
volleyball pit. However, because of the substantial differences between this sand and regolith 
simulant, these tests were non-ideal and led to some serious miscalculations. This year, the team 
constructed and tilled its own arena, in order to test the robot in a more controlled environment. 
Since the competition simulant, BP-1, is not commercially available, the team filled the arena 
with the best analogue they could obtain, namely masonry sand. This sand is finer than the sand 
in the volleyball pit. and provides a better approximation of regolith properties. Tests conducted 
in this arena will be referred to as “on regolith" tests. 



Figure 7. Preparation and use of the testing arena. 


5.2.5 Master List of Tests 

• Mechanical Tests: 

o Motor and gearbox integration test 
o Suspension system integration test (/w temporary wheels) 
o Digging drum support arm integration and movement test 
o Digging drum integration rotation test 

• Computer Tests: 
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o Vision System test 
o Code verification in test bed 

• Electrical Tests: 

o Test COTS voltage regulator 
o Test COTS motor controllers and microcontroller 
o Test I R beacon and sensor 

• Integrated System Tests (involve combinations of the three first-level subsystems): 

o Locomotion test 
o Obstacle climbing test 
o Kinect pan system integration test 
o E&D System movement and control test 
o E&D System test on regolith 
o Movement test on regolith (w/ competition wheels) 
o Suspension test on regolith 

o Combined Locomotion and E&D System test on regolith 
o Vision test on robot 
o Movement control test on robot 
o Full autonomous operation test on robot 
o Full Lunabot system test / competition trial runs on regolith 



Figure 8. The 2012 MSU Lunabotics team with Montana ALE as it nears completion. 


6 Concluding Remarks 

The Montana State University Autonomous Lunar Explorer (ALE) is a complicated 
project which must be spread across a relatively large team of students and requires substantial 
interdisciplinary effort. Since it is intended to enter the official NASA Lunabotics Mining 
Competition, the project also includes many pre-defined and unalterable requirements and 
deadlines. Throughout the project, the principles of Systems Engineering have aided the team in 
organizing and maintaining quality in their work. As of this writing, they are hard at work on the 
remaining implementation and testing tasks, and expect to deliver a complete, working Lunabot 
by the shipping deadline (May 9). 
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